Interesting approach! I appreciate that you added the comment about how the random.sample function works. It's a good idea, at this stage, to include comments like this when using functions from imported modules we haven't covered in the curriculum.

Expanding on that, it's wise to remember that not every language has the same built-in functions, so we should be able to implement this same functionality ourselves. In the projects, we don't ask for any features that we don't think you should be able to write yourself. For drawing a random hand, the only external function that would be "required" is a way to pick a random number (such as randint). At this stage in our coding journeys, it's often more valuable to re-implement things by hand to practice thinking about how to break down and approach the problem at hand, than to use a single library function to solve the problem for us.

This is an interesting approach to this data structure! A nested dictionary can sometimes be tricky to work with, especially if it's going to be transformed or looped over (with or without nesting) so we'll see how it fares in the code below!

This works perfectly well! One thing to note is that you're looping through every letter in word on line 127 and then you're using the in operator to check if the letter is in the copy_letter_bank on line 128. Recall that using the in operator has O(n) time complexity, as does your for loop, so we've got O(n^2).

Rather than using a list of the letters in the hand, could we build a helper data structure (like a dictionary) that could let us look up the number of tiles remaining of each type?

If you have a frequency dict and then check if a key is in the dict, then you can leverage the fact that dicts constant time lookup (in contrast to the list's linear time look up).

This loop works for sure, but you could save the additional complexity of the inner for-loop and just use the dictionary itself, e.g.

        score += LETTER_POOL_W_VALUES[letter]["value"]

👍

No big deal, but since we didn't make any substantive changes to this file, it didn't need to be committed.

This approach does pass the test, but consider the tuple you're returning, which has three elements although the README instructions say to return a tuple with 2 elements (the word and the score). The tests pass because we're testing for the first and second elements of the tuple, e.g.

assert the_tuple[0] == "stuff"

But if we tested for the length of the tuple or for the explicit tuple, the test would fail, e.g.

    assert len(best_word) == 2

In this approach, it's a bit hard to mentally track the indices referred to, so it might be worth unpacking the elements into variables, in order to improve readability.